The field of the present invention generally relates to networking, and more particularly, to methods and techniques for hosting internet services on a network.
The Internet has become a very popular global electronic communication network that has brought about a wide variety of on-line services and development of the World Wide Web (WWW). The number of computers and users accessing the Internet continues to increase rapidly.
Computers on the Internet generally exchange information in the form of packets or datagrams with each other using unique addresses, known as host addresses. The most common form of a host address is an Internet Protocol (IP) address, which is presently a four part sequence of numbers that uniquely identify a particular computer on the Internet. An example of a host address is the IP address xe2x80x9c206.71.200.33xe2x80x9d.
Users commonly access the Internet through one or more clients and servers. Each client and server generally consists of hardware equipment executing one or more software processes that maintain connections to various networked computers. Perhaps the most common tool employed by users for connecting to the Internet is a client or user program called a xe2x80x9cbrowserxe2x80x9d. Netscape Corporation""s Navigator and Microsoft Corporation""s Internet Explorer are two forms of browsers, also known as xe2x80x9cweb clientsxe2x80x9d. Other forms of interaction on the Internet include electronic mail (e-mail), wherein one user sends electronic messages addressed to another user, usually through a mail client such as Qualcomm""s Eudora Lite mail client.
Users generally do not use host addresses to connect their clients to remote computers or servers on the Internet. Rather, users employ host names, or xe2x80x9cdomain namesxe2x80x9d to access a particular computer or server on the Internet. In current Internet parlance, domain names are generally comprised of alphanumeric characters that correspond to a host address on the Internet. An example of a domain name is xe2x80x9cyahoo.comxe2x80x9d.
Domain names generally comprise multiple parts. A root name or top level domain is the ending suffix on a domain name. Examples of top level domains, or root names, include xe2x80x9ceduxe2x80x9d, xe2x80x9ccomxe2x80x9d, and xe2x80x9corgxe2x80x9d. Second level domains immediately follow a top level domain (generally a period, also known as xe2x80x9cdotxe2x80x9d, separates levels of a domain). Examples of second level domains include xe2x80x9cmitxe2x80x9d, xe2x80x9cyahooxe2x80x9d and xe2x80x9cicannxe2x80x9d. Multiple additional domain levels can be added to a domain to yield a complete domain name, such as xe2x80x9cwww.yahoo.com.xe2x80x9d
As used in a web client, the domain name might be xe2x80x9chttp://www.yahoo.comxe2x80x9d (the xe2x80x9chttp://xe2x80x9d portion specifying the hypertext transfer protocol (HTTP) proxy), whereas in a mail client, the domain might be in the format of an e-mail address, such as xe2x80x9cmailto:alice@smith.comxe2x80x9d (the xe2x80x9cmailto:xe2x80x9d portion specifying the simple mail transfer protocol (SMTP) proxy).
To provide a transparent mapping between host names and host addresses to users, a domain name system is employed. The domain name system, or DNS, in current use on the Internet is generally described in a technical specification known as Internet RFC 1034, entitled xe2x80x9cDomain Namesxe2x80x94Concepts and Facilities,xe2x80x9d and additional features thereof are described in a related technical specification known as Internet RFC 1035, entitled xe2x80x9cDomain Namesxe2x80x94Implementation and Specification,xe2x80x9d both of which are authored by P. Mockepetris.
The domain name system described in RFC 1034 has three major components: (1) domain name space and records, which collectively comprise a tree-type data structure used for the mapping; (2) name servers, which are server programs that hold information about the tree structure and point to other name servers that hold information about the tree structure; and (3) resolvers, which are client programs that extract information from name servers in response to client requests.
One configuration for a domain name system (DNS), and the DNS envisioned by RFCs 1034 and 1035, is depicted as a flow diagram in FIG. 1. A shared database holds domain space data for a local name server and a resolver that are associated with a local host.
The contents of the shared database will typically be a mixture of authoritative data maintained by periodic refresh operations from master files by the name server, and non-authoritative cached data from previous resolution requests or maintenance queries that were answered by one or more foreign name servers. The contents of the shared database are generally in the form a flat file comprising a plurality of resource records (RRs). Resource records correlate a particular host name or domain name with its host address and other protocol information on the Internet. As such, resource records generally comprise a number of fields. It should be noted that the name server is responsible for maintaining current resource records for the domain names for which it is the authority and any other non-authoritative domain names specified by the domain name system.
The shared database is generally not a typical database. The shared database is called such because it represents a plurality of resource records distributed among various computer systems (or other domain name systems) throughout the Internet. Although the shared database might have somewhat current resource records for which it is the authority (or in its xe2x80x9czonexe2x80x9d), the resource records for which it is not the authority must be periodically updated or xe2x80x9crefreshedxe2x80x9d from multiple foreign resolvers or from foreign name servers. Theses refresh operations are performed to account for changes in the mappings between host names and host addresses. This process occurs for authoritative resource records too. The shared database is thus a distributed resource record database and is inextricably tied to other authoritative domain name systems on the Internet in order to operate in view of RFC 1034 and 1035. As such, a highly coherent or synchronized view of the database is unlikely, given the highly distributed nature of the Internet and the number of domains therein.
When a user program, such as the browser, requests information from, or attempts to send information to a particular host name, a resolution request is passed in the form of a query to the resolver. The query uses as arguments a proxy, a host name, and other data. The resolver will check the shared database for a corresponding host address to the host name in the shared database or from the name server. If a corresponding resource record exists in the shared database, it will be returned to the resolver and then to the user program. However, if a resource record does not exist, then the resolution request is passed on to a local name server (for authoritative data) or to a foreign name server (for non-authoritative data).
The set of domains for which a particular name server is the authority is commonly referred to as a zone. Data outside the zone is the responsibility of another name server. When a resolution request is made for non-authoritative dataxe2x80x94data that is also not present in the shared databasexe2x80x94the response is handled as a xe2x80x9czone transferxe2x80x9d. To resolve the resolution request, the request is passed on to a foreign name server, preferably the name server that is the authority for the domain name. Various techniques can be employed to resolve such requests for non-authoritative data.
In particular, it is noted that because a foreign name server will resolve such requests, the latency between the query and the response can be great. The prior domain name system, as described in RFC 1034, envisions that zone transfers should be non-blocking, meaning that zone transfers should be handled immediatelyxe2x80x94that a second zone transfer should not wait for a first zone transfer to be completed before handling the second zone transfer. Thus, valuable execution processing cycles will not be wasted while the foreign name server performs the work.
However, when authoritative requests are made or requests for non-authoritative data that is contained in the shared database, known domain name systems block concurrent or subsequent requests until earlier requests have been handled. This is likely so because the name server can be responding to either local or foreign resolvers and because the authoritative name server must perform the work dictated by the request, such as checking resource records and formulating a response. The responses, of course, can vary depending on the type of the request, such as a mail exchange, hypertext transfer protocol, etc. Handling the resolution request can also involve querying foreign resolvers and/or foreign name servers. The varied nature of the work performed by the name server suggests that it is either not efficient, or not prudent to share execution memory or resources when responding to resolution requests where the name server must perform the work. Moreover, the existing domain name system was designed to be portable, meaning it is capable of running on a variety of operating systems. However, there is no good portable multi-threaded application programming interface available on the market today. Furthermore, the overhead involved with multi-threading simply is not effectively amortized over the small number of domain names most domain name systems support.
One option to overcome the drawbacks of overworking a domain name system is to employ multiple name servers and attempt to balance the workload on each name server. A separate computer system, a load balancer, is disposed between remote systems and multiple name servers. The load balancer intercepts incoming resolution requests and assigns those requests in a round-robin fashion to one of the multiple name servers. Such a technique, however, can further drain existing system resources, and it can require additional hardware (e.g., a separate computer system for each name server) to implement. Additionally, redundant information must be stored in each of the multiple name servers such that each name server is capable of handling the same sets of authoritative and non-authoritative resolution requests.
Perhaps the most common domain name system software used today is the Berkeley Internet Name Domain, commonly referred to as xe2x80x9cBINDxe2x80x9d. BIND (the most current version of BIND is Ver. 8.2) is an open source, general purpose implementation of a domain name system protocol.
Whereas BIND may be adequate for most large-scale hosts supporting a limited number of domains, BIND may not be suitable, or may prove to be inadequate, for systems in which the host is designed to be a name server for many domainsxe2x80x94particularly in the order of the thousands or more of domain names.
For example, one drawback to BIND is that when resource records are updated, the host software often needs to be restarted, causing undesirable delays or down time. Another drawback or limitation is that BIND is a blocking server, meaning that only one xe2x80x9cthreadxe2x80x9d exists for answering queries to resolve a domain name in the server""s zone. (As used herein, a xe2x80x9cthreadxe2x80x9d refers to a part of a computer software code that can execute independently relative to other parts of the code.) The BIND system described above, xe2x80x9csingle threadedxe2x80x9d, meaning that its code may activate more than one processor, but it does so in a way that at any given time only a single processor is activexe2x80x94only one thread is allowed to answer queries in the server""s zone at a particular time. If a name server using BIND serves hundreds, or thousands, of domain names, the latency between a resolve request and the response can be significant.
These limitations or drawbacks to BIND are compounded by the fact that growth of the Internet is continuing to expand at a very rapid rate, which results in the constant addition of a large number of new domain names on a daily basis. This rapid growth of domain names is stressing the infrastructure of the Internet. Resource records need to be frequently updated, and IP addresses sometimes change. Since BIND often requires the host software to be restarted when resource records are updated, a system based on BIND is not well suited to maintaining an ever-expanding collection of domain names. Further, BIND, in its present implementations, lacks a suitable mechanism for handling the potentially large number of queries to resolve domain names where the system has hundreds or thousands of domain names and is continuously expanding.
Given the growth of the Internet and the fact that many casual users of the Internet would like to maintain domain names, but are often unable to do so due to costs associated therewith, the inventors have recognized that it would be advantageous to provide an improved name server and domain name hosting system that is scalable and that is able to answer simultaneous requests for thousands of different domain names, and to implement such a system on a single computer system or network.
A method and apparatus for providing domain name services is provided. According to one aspect of the invention, a multi-threaded name server handles multiple concurrent name requests, and is particularly well suited for a host system controlling information relating to a large number of domain names. In a preferred embodiment as described herein, a multi-threaded name server comprises a request dispatcher thread capable of spawning multiple child threads. For each name request received by the request dispatcher thread, the request dispatcher spawns a child thread to handle the request. The child threads query a host name cache to determine whether the host name cache comprises a host name matching a host name in the name request. The result is a multi-threaded, non-blocking name server capable of handling multiple concurrent name requests for a large number of domain names.
In one embodiment, one or more additional network services are also provided, preferably using a centralized database. For example, in a particular embodiment, electronic message forwarding services are provided wherein an advertisement is associated with an electronic message based on the message contents. In another embodiment, web services are provided wherein hypertext markup language (HTML) pages are dynamically generated. In still another embodiment, both electronic message forwarding services and web services are provided on by the same system using the centralized database.
Further embodiments, enhancements and variations of the foregoing are also described herein.